Summary Enterprise API integrations require more than simply obtaining an access token. The authentication model must provide a reliable way for an application to establish its identity while protecting the credentials used to do so. In this implementation, we explored a certificate-based authentication architecture using Microsoft Entra ID, an X.509 self-signed certificate, Azure Key Vault, Azure Functions, Managed Identity, and Microsoft Authentication Library (MSAL). The objective was to replace dependency on an expiring client secret with a certificate-backed application identity, while keeping the private certificate protected within Azure infrastructure. This article walks through the complete implementation — from creating the certificate and registering its public key, to storing the private certificate in Key Vault, configuring the Function App, and ultimately obtaining an OAuth 2.0 access token through MSAL. Table of Contents Introduction The Business Requirement Why Certificate-Based Authentication? Solution Overview The Authentication Architecture Step 1 — Creating the Microsoft Entra App Registration Step 2 — Creating the Self-Signed Certificate Step 3 — Exporting the Certificate Step 4 — Importing the Private Certificate into Azure Key Vault Step 5 — Registering the Public Certificate with Entra ID Step 6 — Creating the Azure Function Step 7 — Enabling Managed Identity Step 8 — Granting Key Vault Access Step 9 — Configuring Function App Settings Step 10 — Implementing Certificate Authentication with MSAL Step 11 — Obtaining the Access Token Understanding the Client Assertion Security and Production Considerations Key Implementation Lessons Frequently Asked Questions Conclusion Case Study Read more about our Journey with this Customer over here: View Case Study Introduction Enterprise applications increasingly depend on APIs to connect business processes across platforms. Microsoft Partner Center and other Microsoft services provide powerful APIs for automation, reporting, partner operations, customer processes, and broader Microsoft ecosystem integrations. As an integration moves toward production, however, authentication becomes an architectural concern rather than simply a configuration task. A client secret may be sufficient during initial development, but production integrations introduce additional questions: How should application credentials be protected? How should credentials be rotated? How can private credentials be kept outside application code? How can authentication be centralized for multiple consumers? How can the solution reduce dependency on manually managed secrets? These considerations led to a certificate-based authentication approach: Use a certificate-backed application identity, protect the private certificate in Azure Key Vault, and use an Azure Function with Managed Identity and MSAL to obtain the downstream access token. The implementation described in this article demonstrates that architecture from beginning to end using a self-signed certificate as the initial certificate credential. The Business Requirement The requirement was to establish an application-to-application authentication mechanism for Microsoft API integrations without relying on a long-lived client secret embedded across application components. The traditional client-secret model is straightforward: Application ↓ Client ID + Client Secret ↓ Microsoft Entra ID ↓ Access Token ↓ Target API The challenge is that the client secret behaves like a password. It must be securely stored, rotated, replaced before expiration, and carefully distributed to every application or service that needs it. The target architecture instead establishes application identity using a certificate: Application ↓ Certificate-backed application identity ↓ Microsoft Entra ID ↓ Access Token ↓ Target API Azure Key Vault then provides the security boundary for the private certificate material. Why Certificate-Based Authentication? Certificate authentication is based on asymmetric cryptography. The certificate contains a public key and corresponds to a private key. The public certificate can be registered with Microsoft Entra ID, while the private key remains protected by the application infrastructure. Microsoft Entra ID │ Public Certificate │ │ validates ▼ Azure Function ────── Signed Assertion │ │ └── Private Key protected by Azure Key Vault The important difference from a client secret is that the application proves possession of the private key rather than sending a reusable password-like credential as its application credential. Microsoft Authentication Library (MSAL) supports certificate credentials for confidential client applications. In MSAL.NET, the .WithCertificate() configuration allows MSAL to use the certificate to perform the client authentication process. Solution Overview End-to-end certificate-based authentication architecture The implementation separates authentication responsibilities across several Azure and Microsoft identity components. Component Responsibility Microsoft Entra App Registration Represents the application identity Public Certificate Registered with Entra ID to validate the application Private Certificate Used to prove possession of the registered certificate Azure Key Vault Protects the private certificate material Managed Identity Allows the Function App to access Key Vault without another secret Azure Function Centralizes token acquisition MSAL Handles the OAuth 2.0 client-credential authentication process Access Token Used to authorize requests against the target API The Authentication Architecture The complete authentication sequence can be simplified to: 1. Application calls the authentication Function ↓ 2. Function authenticates to Azure Key Vault using Managed Identity ↓ 3. Function retrieves the private certificate ↓ 4. MSAL loads the certificate ↓ 5. MSAL creates the signed client assertion ↓ 6. Assertion is sent to Microsoft Entra ID ↓ 7. Entra validates the certificate ↓ 8. Entra issues the access token ↓ 9. Function returns the access token ↓ 10. Consumer uses the token against the target API The key architectural separation is that the consumer does not need to manage the private certificate directly. The authentication layer manages certificate access and token acquisition. Step 1 — Creating the Microsoft Entra App Registration The first step is to create an App Registration representing the application that will authenticate with Microsoft Entra ID. For this implementation, the test application registration was: skenycerttestappreg The App Registration provides the application’s Client ID and Tenant ID and acts as the identity against which the certificate credential is registered. The App Registration stores the public certificate credential. It does not require the private key to be uploaded to Entra ID. Step 2 — Creating the Self-Signed Certificate For the initial implementation, a self-signed certificate was created locally using PowerShell. $cert = New-SelfSignedCertificate ` -Subject “CN=Test App Registration Certificate” ` -CertStoreLocation “Cert:\CurrentUser\My” ` -KeyExportPolicy Exportable ` -KeySpec Signature ` -KeyLength 2048 ` -NotAfter (Get-Date).AddYears(2) This creates a certificate … Continue reading From Client Secrets to Certificate-Based Authentication: Building a Secure Integration with Azure Key Vault and Azure Functions for a US based AI & Cyber Security Company →

One Data Platform, Future-Ready for AI – Power BI Report Migration to Azure Databricks Summary Every organization wants to be AI-ready. Very few are data-ready. Business data typically lives across ERP, CRM, HR, and finance systems, each handled differently and reported separately. The result is familiar to most leadership teams: reports that do not agree, logic rebuilt in every dashboard, and AI initiatives that stall because the data underneath them cannot be trusted. This article makes the case for one data platform – a single, governed foundation where all business data is brought together, processed consistently, and made ready for both reporting and AI. We share how we built this at CloudFronts on Azure and Databricks, unifying five business systems and migrating 40+ Power BI reports with zero downtime, and why that foundation is what makes AI use cases practical rather than aspirational. Table of Contents 1 The Hidden Cost of Scattered Data 2 What One Data Platform Really Means 3 Why It Matters to the Business 4 Solution Architecture Overview 5 Migration Without Disruption 6 From Reporting Platform to AI Foundation 7 AI Use Cases It Unlocks 8 Scattered vs Unified 9 Questions Every Leader Should Ask 10 Where to Start 11 FAQs 12 Conclusion The Hidden Cost of Scattered Data Most growing organizations do not set out to fragment their data. It happens one decision at a time. A new ERP for finance. A CRM for sales. An HR system for people. An accounting tool for a specific entity. Each one solves a real problem – and each one becomes another separate source of data. This project started with our own reporting. Like many growing services organizations, CloudFronts runs its business across several systems: Business Central and Finance & Operations for ERP, Dynamics 365 CRM for clients and engagements, Zoho People for HR, and Zoho Books for accounting. Leadership, finance, HR, and delivery teams rely on more than 40 Power BI reports built on these systems, from management dashboards and HR reports to the Steering Committee report we use to track quarterly meetings with client accounts. Over time, each system had been connected in its own way. Some data moved through Azure Data Factory, some through SQL Database, and some through Azure Functions. Reports connected directly to their sources, with business logic built inside each one, and they sat across separate workspaces for HR, management, and other teams. The idea behind the project was simple: instead of continuing to add pipelines and reports system by system, bring all business data into one trusted platform on Azure Databricks, migrate every existing report onto it without disrupting the people who use them, and build a foundation that is ready for AI in the process. None of the old setup looked broken on any given day. But the costs were real, and they compounded as the business grew. Numbers That Do Not Agree When the same metric is calculated in several reports, small differences appear. Leadership meetings start with reconciling numbers instead of acting on them. Effort That Keeps Growing Every new report means another connection, another copy of the logic, and another refresh to maintain. The effort grows with every report added. Governance That Is Hard to Enforce When reports sit in different workspaces with different owners, controlling who sees what becomes a manual, error-prone exercise. Data That Is Not Ready for What Is Next AI and advanced analytics need clean, connected data. Scattered data means every AI idea starts with a data consolidation project first. “The data was never the problem. The problem was that it lived in five places, and every system handled it differently.” What One Data Platform Really Means One data platform is not just a new database or a bigger data warehouse. It is a change in how the organization treats its data – from something each system and report manages on its own, to a shared business asset managed once, for everyone. Functionally, it comes down to four commitments: 1One place for all business data – Every source system feeds a single platform, so finance, sales, HR, and operations data sit side by side and can be connected. 2One way of processing it – Every source goes through the same standardized stages, so data is cleaned and shaped consistently no matter where it came from. 3One definition of every business rule – Business logic – how revenue is grouped, how a meeting is classified, how an employee is counted – is defined once and reused everywhere. 4One layer of governance – Access is controlled centrally by role, so the right people see the right data without each report owner managing permissions separately. Why It Matters to the Business For leadership, the value of one data platform shows up in outcomes rather than architecture. A Single Source of Truth Every report reads from the same curated data, so the numbers agree across finance, operations, and management reporting. Faster Answers, Less Rework New reports and new data sources are added through configuration, not rebuilt from scratch. Teams spend time on insight instead of plumbing. Stronger Governance by Design Centralized, role-based access means security is enforced by the platform, not by individual report owners. Lower Long-Term Complexity One pipeline and one framework replace a patchwork of tools, reducing maintenance and dependency on specific individuals. Scales With the Business Adding a new system or entity follows the same pattern, so growth does not multiply reporting complexity. A Foundation for AI Clean, connected, governed data is exactly what AI, machine learning, and process mining need to deliver reliable results. Solution Architecture Overview We built our one data platform on Azure and Databricks. Here is how it fits together, from five source systems to a single, governed Power BI workspace. How the Architecture Works Step 1: Connect the Source SystemsBusiness Central, Finance & Operations, Dynamics 365 CRM, Zoho People, and Zoho Books are registered once in a central ingestion list that tells the platform what data to bring in. … Continue reading From Multiple Data Sources to Azure Databricks: A Zero-Downtime Power BI Migration for Future AI Readiness →

Summary Most organizations implement AI in a set sequence – connect systems, clean the data, then govern and track adoption. That is the right path, but we could help ourselves by implementing AI that eases the “Clean Data” process itself. This post flips the script: instead of using AI only for insights, use it to flag what is missing, overdue or stale in your Opportunities. An example from the Sales Opportunities review portal we run at CloudFronts shows how a Pipeline Risk area instils the habit of keeping Dataverse / D365 Sales data correct, so the AI that follows is closer to accurate. Related reading: Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders and our AI Managed Services Agreement. Table of Contents 01Summary 02Where We Are on the AI Journey 03AI For Clean Data 04Example 05Conclusion Where We Are on the AI Journey We are somewhere on the journey in implementing AI at our organization. And in this process, we often are looking to implement AI in the organization in the below sequence – Connect systems via robust integrations. Clean the data for Analytics and AI. Implement AI governance and track adoption. While this is the right path to implement AI, we stick to the plan in implementing AI. And this isn’t incorrect. However, we could help ourselves by implementing AI that promotes easing the “Clean Data” process. AI For Clean Data So, let’s flip the script for a bit – “Clean Data for AI” can start with “AI for Clean Data”. Let me explain with a use case – You are a Sales Lead at a professional services firm. You are supposed to make sure Opportunities are correctly tracked with the right probabilities, follow ups and have clean prospect data in them. Now, implement an AI that flags the data discrepancies instead of typically using AI for “AI Insights”. Let AI tell you – “Something is missing” “Something is overdue” “You have not communicated yet” “There’s no address or website for the Opportunities” “Revenue numbers or follow up dates are missing” Now most times, it might not be relevant to put this info – there can always be 5% exception in the data. However, this promotes cleaning the data that matters for the actual AI to implement by instilling good habits. Example Now, I’m running this portal for the Sales Opportunities review of the Management. I’m supposed to keep the Opportunities always updated for the management to have a true view of the pipeline and probabilities. The Sales Opportunities review portal – pipeline by quarter and Hot Opportunities, with the Pipeline Risks area running down the left. Due to busy schedule, things can fall through and the data continues to become stale and outdated. It might not show what Opportunities really are Hot or it might show some other Opportunities as Hot because I didn’t update the notes when probability dropped. So to tackle this problem, on the main pane itself – I’ve added a Pipeline Risk area. This will look at the existing data and flag me anything which should be incorrect. The Pipeline Risk area flags what looks incorrect – overdue deals, stalled engagement, accounts with no recent activity notes. Now whether it is true or not is up to me – but this puts me in a habit to make sure I always update my Dataverse / D365 Sales Opportunities correctly, so the AI Summary for Hot Opportunities improves and shows relevant data at all times. Now if you extrapolate these to bigger actions across all AI implementations of flagging incorrect data to the end user – it promotes good habits that make the intended AI to be closer to accuracy in its own non-deterministic nature. This is what is implemented at CloudFronts for our Sales efforts and similar versions are implemented for our customers using Dynamics 365 CRM/Sales for their implementations. Conclusion This might be a small trigger for a human change, but it has its compounding effects in implementing AI at your organization that directly co-relate to a production use case being a success or a failure. Human-in-the-loop is very much a reality and a necessity that we think it is. Further, the higher order of AI implementations like automated decision making can follow. Want AI That Keeps Your CRM Data Honest? If you’re exploring how to put AI on top of Dynamics 365 or Dataverse, we’d be glad to talk through where it makes sense to start. Keeping this running beyond the first use case is what our AI Managed Services Agreement is built for. Contact Us AI Managed Services Agreement Priyesh Wagh Microsoft AI ERP MVP, Practice Manager · cloudfronts.com Priyesh Wagh is a Practice Manager at CloudFronts and Microsoft AI ERP MVP. Priyesh works with his team in delivering Dynamics 365 business applications implementation to CloudFronts global customers, mainly in the US and Europe. Connect with Priyesh on LinkedIn.

MRP Batch Trigger Service Summary Planning Optimization (what most F&O teams still call MRP out of habit) normally runs on a fixed recurrence: nightly, or every few hours. That’s fine until an upstream event lands between runs and the plan needs to reflect it before the next window opens. Rather than reconstructing the entire Planning Optimization call from scratch, this post covers a smaller, safer pattern: a custom X++ service that finds the existing, already-configured batch job and flips its status to Waiting, so the batch framework picks it up on its next poll. Same job, same configuration, just triggered early. The example is drawn from an engagement with a North American truck manufacturer, where an upstream integration needed to nudge Master Planning immediately after a data load rather than wait out the scheduled recurrence. On this page 01The business trigger 02Why reuse the batch job, not rebuild the call 03Where the batch job’s RecId comes from 04The service class 05Exposing it as a callable service 06Gotchas worth knowing 07FAQs 08Conclusion The business trigger Planning Optimization is normally left alone once it’s configured: coverage groups, item coverage, and a batch recurrence tell it when to run, and most days that schedule is all anyone needs. The gap shows up when a trigger for a fresh plan doesn’t come from the calendar; it comes from another system. A large sales order import lands late, an engineering change lands mid-afternoon, or an upstream integration finishes a nightly sync on its own schedule, and the planning team needs the recalculated plan before the next window opens, not after. Manually opening Master Planning parameters and clicking “Run now” doesn’t scale when the trigger has to come from outside the ERP entirely. Why reuse the batch job, not rebuild the call Planning Optimization isn’t a simple in-process function call. The batch task hands off to an Azure-hosted optimization engine, carrying policy and configuration that already lives in Master Planning setup: coverage groups, item coverage codes, the plan itself. Reconstructing that entire call from a custom service would mean duplicating configuration the system already tracks, and keeping two copies of it in sync forever. The simpler move: find the batch job the system already runs on its recurrence, and change its status so the batch framework picks it up on the next poll instead of waiting for the scheduled time. Same job, same configuration, just triggered early. Where the batch job’s RecId comes from The service doesn’t look the batch job up by caption at runtime; captions get renamed, retranslated, or duplicated, which makes name-matching fragile. Instead, the correct job’s RecId is captured once, during setup, and stored on a custom parameters table (here, a field on ReqParameters). The trigger call then becomes a single indexed select instead of a caption search. Ops note: because the pointer is a raw RecId, it breaks silently if the batch job is ever deleted and recreated. An LCS environment refresh or a redeploy of the batch setup is enough to do it. Re-capture and re-save the RecId as part of any environment refresh checklist. The service class The method is deliberately thin: find the configured batch job, flip its status inside a transaction, and report back what happened. CFMRPOptimizationBatchTriggerService.xpp internal final class CFMRPOptimizationBatchTriggerService { public CFMRPOptBatchTriggerServiceResponseContract triggerMRPOptBatchJob() { CFMRPOptBatchTriggerServiceResponseContract response = new CFMRPOptBatchTriggerServiceResponseContract(); try { BatchJob batchJob; select firstOnly forUpdate batchJob where batchJob.RecId == ReqParameters::find().MRPOptBatchJobRefRecId; if (!batchJob.RecId) { response.parmMessage(“Planning Optimization batch job was not found.”); } else if (batchJob) { ttsbegin; batchJob.selectForUpdate(true); batchJob.Status = BatchStatus::Waiting; batchJob.update(); ttscommit; response.parmMessage(strFmt( “Planning optimization batch job found and triggered. ID: %1, Description: %2, Status: %3”, batchJob.RecId, batchJob.Caption, enum2Str(batchJob.Status))); } } catch (Exception::Error) { response.parmMessage(“Trigger failed”); } return response; } } Three things worth calling out in that order of execution: The initial select firstOnly forUpdate locates the job and prepares it for a later update, but it sits outside any transaction at that point. The real lock happens with the selectForUpdate(true) call just before ttsbegin, which is what actually matters for correctness under concurrent triggers. Flipping Status to Waiting is the entire “trigger.” Nothing here talks to the Planning Optimization engine directly; that’s the batch framework’s job once it sees a waiting task. The response contract carries a single human-readable message, which is enough for a calling system to log success or failure without needing to parse the batch job’s internal state itself. Exposing it as a callable service The class itself is just X++. Making it callable from outside the ERP is a standard AOT step: 1Add an AOT Service node referencing this class and the triggerMRPOptBatchJob method. 2Add the service to a Service Group and deploy. F&O exposes it over the standard integration endpoint once deployed, callable from an integration platform or middleware without any custom endpoint code. 3Have the calling system read parmMessage to confirm the job was actually found and flipped, rather than treating a successful call as proof that MRP ran. The trigger is fire-and-forget from the batch engine’s side. Gotchas worth knowing “Waiting” is not “running now.” The status change queues the job for the batch server’s next poll, typically seconds to a couple of minutes later depending on batch server load, not a synchronous MRP run. Don’t build a caller that blocks waiting for a result. The catch block swallows the real error. catch (Exception::Error) returns a flat “Trigger failed” with no diagnostic detail retained. That’s fine for a demo; in production it means the caller, and whoever gets paged, has no idea why it failed. Worth extending to log the actual exception before returning the generic message. Retriggering a running job is harmless, but a symptom. Flipping an already-Executing job back to Waiting doesn’t start a second concurrent run. If a caller is doing that repeatedly in a tight retry loop, though, it’s usually a sign the caller isn’t checking the response message before retrying. “A trigger service doesn’t need to reimplement what Master Planning already knows how to run. It only needs to … Continue reading How a Leading North American Commercial Vehicle Manufacturer Triggers MRP On Demand Using a Custom X++ Service in Dynamics 365 Finance & Operations →

01Summary Project-based businesses often run their projects in Dynamics 365 Project Operations and their finance in Dynamics 365 Business Central. The two systems do not talk to each other out of the box, so every customer, project, timesheet, expense and invoice ends up being typed into both, and the numbers finance reports on are always a step behind the project teams. CloudFronts built an integration that closes this gap using Dataverse plugins: small pieces of C# code that run inside Project Operations every time a record is saved. When someone creates a customer, sets up a project, approves a timesheet or confirms an invoice, the plugin sends that record straight to the matching Business Central web service and writes the Business Central number back onto it. Before material is used on a project, it looks up how much stock Business Central holds at that location. Anything that fails is saved in an Error Log with the exact data that was sent. To keep the examples concrete, this post follows a sample scenario: Wexford County Council orders a satellite broadband installation at its Castlemoyle and Bunclody water treatment sites, and the project runs from the first lead to the final invoice across both systems. Table of Contents 01Summary→ 02Business Challenges→ 03Solution Overview→ 04Technical Approach→ 05Business Impact→ 06Conclusion→ 02Business Challenges Project Operations and Business Central each work well on their own. The trouble is the gap between them: nothing entered in Project Operations reaches Business Central unless someone types it in again. Without an integration, teams run into the same problems: Everything is entered twice. A new customer or project is created in Project Operations, then created again in Business Central. Every later change has to be repeated by hand. Master data drifts apart. Countries, postcodes, currencies, payment terms, dimensions and work types have to match in both systems. When one side changes and the other does not, records fail to post. Approved work reaches finance late. Approved timesheets, expenses and material only arrive in Business Central after someone exports and imports them, so project costs in finance are always behind. Material is used without checking stock. Site teams log material against a project without knowing whether Business Central actually has it at that location. Invoices are keyed twice. A confirmed project invoice has to be rebuilt in Business Central, line by line, before finance can post it. Errors are hard to trace. When a record does not match, nobody can see what was sent or why Business Central rejected it. 03Solution Overview CloudFronts built one main plugin, RequestProcessor, and registered it on every Project Operations table that finance needs. Two small helper plugins handle the stock check for material. Whenever one of those records is created, updated or deleted, Dataverse runs the plugin. The plugin works out which table the record came from, turns it into the shape Business Central expects, and sends it to the matching Business Central web service. When Business Central replies, the plugin stores the Business Central number on the Project Operations record, such as the BC customer number or the project code. Next time the record changes, the plugin uses that number to update the same record in Business Central instead of creating a new one. All the settings the plugin needs, such as where to sign in, which web service to call for each table, and which user is the integration user, live in a single Integration Configuration record in Dataverse. Moving from a test company to the live one is a change to that record, not to the code. ⓘKey terms, in plain words Dataverse plugin: C# code that Dataverse runs automatically when a record is saved, like a trigger in a database. Business Central web service: an address in Business Central that accepts records from other systems, one for customers, one for projects, and so on. Project Journal: where costs are recorded against a project in Business Central before they are posted. Project Planning Lines: the budget of a project in Business Central. ⓘWhy a plugin instead of Power Automate? A cloud flow could copy simple records, but this integration covers 20 tables with detailed mapping rules for each one. In a plugin, that logic lives in one C# project that can be versioned, reviewed and tested like any other code. The plugin runs the moment the record is saved, only on the tables and messages it is registered for, and it ships in the same Dataverse solution as the rest of the Project Operations customisation. 04Technical Approach How It Works Every save takes the same path through the plugin: A record is saved in Project OperationsFor example, the project manager approves a week of time entries on the Wexford County Council broadband project. RequestProcessor loads its settingsIt reads the Integration Configuration record. If the record is missing, the plugin stops quietly instead of failing the user’s save. It skips its own changesIf the record was last modified by the integration user, the plugin stops. This keeps it from running again on the Business Central number it has just written back. The handler for that table maps the recordIt checks the record’s status, so only approved entries or confirmed invoices go further, and copies the fields into the JSON shape Business Central expects. Business Central creates or updates the recordPOST creates a new record; PUT updates the one already linked by its Business Central number. The result is savedOn success, the Business Central number is written back onto the Project Operations record. On failure, an Error Log record is created with the details. What Moves Between the Systems The plugin handles 20 Project Operations tables. They fall into five groups, in the order a project normally runs. Group Saved in Project Operations Created in Business Central When It Is Sent Customers Account Customer, or Vendor when the account type is Vendor Create and update; a delete blocks the record in BC instead of removing it Customers Contact Contact Create, update and delete … Continue reading How We Built a Project Operations to Business Central Integration Using Dataverse Plugins →

Summary Most project businesses we work with have the same quiet problem. The project team plans and tracks work in Dynamics 365 Project Operations. The finance team bills, buys and closes the books in Dynamics 365 Business Central. Everything the project team decides has to be typed again by finance. The two teams spend their week checking each other’s numbers. At CloudFronts we closed that gap with plugins: small automatic helpers that sit inside Project Operations and act the moment someone saves a record. When a project, a plan, a timesheet or an invoice is saved, the helper creates the matching record in Business Central and writes the Business Central reference back on the project. This integration is available as the PO-BC Integration Module 2.0 on Microsoft Marketplace. To show how this works in practice, we ran a real example through our demo environment: CloudFronts – Smart Office Rollout, Mumbai, a short project to fit out a new office floor. Every screenshot in this post comes from that one project. Table of Contents Summary→ Business Challenges→ The Idea in Plain Words→ Walkthrough: The Mumbai Office Rollout→ What Moves, and When→ The Safety Nets→ What We Learned Building It→ Business Impact / Key Takeaways→ Questions We Get Asked→ Conclusion / Final Thoughts→ Call to Action / Connect With Us→ Business Challenges Picture the Mumbai office rollout without any connection between the two systems. Monday. The project manager sets up the project, splits it into four tasks and plans 104 hours of work in Project Operations. Finance is told about it in an email. Tuesday. Finance creates the same project in Business Central, retypes the four tasks, and builds a budget from a spreadsheet the project manager sent over. One task name is spelt differently. Nobody notices. Wednesday. The plan changes: cabling needs an extra day. Project Operations is updated. The budget in Business Central is not. Thursday. Twenty desks are taken from the warehouse for the new floor. The site team records it in Project Operations. Business Central still believes the desks are on the shelf. Friday. Finance asks why the project margin looks wrong. Two people spend the afternoon comparing screens. None of this is anyone’s fault. Each system is doing its job. They just do not talk to each other. The Idea in Plain Words A plugin is a small piece of code that lives inside Project Operations and wakes up at a specific moment, for example when a project is saved or a timesheet is approved. Ours does three things each time it wakes up: It reads what just changedThe project name, the customer, the task, the hours, the item and quantity: whatever finance would otherwise have to retype. It creates or updates the same record in Business CentralIt signs in to Business Central with its own dedicated account, not a person’s login, so it keeps working when people change roles or leave. It writes the answer backBusiness Central replies with its own reference, such as a project number or an invoice number. That reference is saved on the Project Operations record, so both teams can always find the matching record in the other system. 💡Why a plugin and not a scheduled sync? A scheduled sync runs every hour or every night and moves whatever has changed. A plugin acts on the exact save, so Business Central is updated within seconds, and only the record that changed is sent. It is also packaged with the rest of the Project Operations setup, so moving it from the test system to the live one is a single, repeatable step. Walkthrough: The Mumbai Office Rollout Here is the same week again, this time with the integration switched on. The customer is CloudFronts Technologies, already known to Business Central as customer C00310. The work is 40 new workstations, meeting-room screens and office Wi-Fi. The customer account, integrated to Business Central with its customer number sent back. Step 1: The Project Manager Creates the Project, Once The project manager creates the project in Project Operations with a name, the customer, a start date of 12 October and a finish date in December. The project code is left blank because nobody knows it yet. A few seconds after saving, the code J00700 appears in the Project Code field. That number came back from Business Central. The project integrated to Business Central. The project code J00700 was filled in automatically. Step 2: The Tasks Follow The project manager adds four tasks in the project plan: Site Survey and Floor Plan, Network Cabling and Wi-Fi, Workstation and Screen Installation, and Testing and Handover. Each one is created under project J00700 in Business Central with the same name and dates, numbered 1272 to 1275. Finance did not open anything. Step 3: The Plan Becomes the Budget Next, the project manager assigns a named person to each task: 16 hours for the survey, 40 for cabling, 32 for installation and 16 for testing and handover. The integration turns that plan into budget lines in Business Central, one line per working day per person, so finance sees not only how much work is planned but when it falls. Weekends are skipped automatically. Resource assignments from Project Operations, turned into daily planning lines in Business Central. ⓘWhy one line per day? A single line of "104 hours" tells finance the total but nothing about timing. Daily lines let finance see cost landing in October versus November, which matters at month end. If the plan changes, the same lines are updated, not duplicated. Step 4: Real Work and Real Material Arrive as Actuals On 12 October, the consultant logs a day on the site survey: "Walk-through of the new floor; desk layout and cable routes agreed with facilities." A week later, the site team records 20 ATHENS desks taken from the Main Warehouse for the installation task. The integration does not send rough drafts. Time and material only go to Business Central once they are submitted for approval, and the … Continue reading No More Retyping: How We Connected Project Operations and Business Central with Plugins →

Summary A Houston based cybersecurity company came to us with a familiar complaint. Their sales leaders had everything they needed sitting in Dynamics 365, yet every Monday review still started in Excel. They asked for two things: their reports laid out the way they actually think about the business, and an assistant they could simply ask questions. We delivered both in one app, built with Power Apps Code Apps on top of the CRM data they already had. In This Blog What was slowing the sales team down What we built for them, screen by screen The AI agent we added so leaders can just ask What changed for the business How to tell if this approach fits your team Table of Contents Summary→ Business Challenges→ What We Built→ The AI Agent→ How It Works→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges Nothing was broken. The data was good and the team was using the CRM. The trouble was getting answers out of it quickly. A standard view shows you a list of records, which is great when you are working a lead. It is far less helpful when the sales director wants to know how many leads turned into real opportunities this quarter, and who brought them in. So the weekly routine looked like this: Open one view, then another, then a third, to piece the funnel together. Export everything to Excel and rebuild the same pivot table as last week. Walk into the meeting with numbers that were already a few days old. What the team really wanted was simple: better looking reports they could read at a glance, and an AI agent alongside them to answer the questions the reports did not cover. Before Several views to see one picture Weekly exports and pivot tables Numbers out of date by meeting time After Key numbers on the first screen One set of filters for everything Answers by simply asking What We Built Power Apps Code Apps let us design the screens completely from scratch while still reading the same Dynamics 365 data, live. Think of it as a new front door to the CRM, arranged around the questions the leadership team asks every week. Nothing was copied or moved anywhere else. The app has four pages, and they all work the same way, so people only learn it once: LeadsWhere new interest comes from and how much of it qualifies. OpportunitiesThe live pipeline, in the order leadership reviews it. SalesWhat has closed and how the team is tracking. ProjectsWhat happens after the deal is won, from Project Operations. Each page opens with the headline numbers, such as total leads, open leads, qualified leads and the qualification rate. Below that sits a single filter bar for owner, status, account, dates and search. Change one filter and every number, chart and list on the page updates with it. The summary page: headline numbers, a trend over time, and breakdowns by customer, source and owner. Shown with demo data. When a chart raises a question, the detail page shows the actual records behind it, already filtered the same way. The detail page, using the same filters as the charts. Shown with demo data. The AI Agent The second half of the request was an assistant. Code Apps do not include one, so we built our own AI agent and placed it in a side panel inside the app. Leaders type a question the way they would ask a colleague, and the agent answers from the live CRM data. Questions like which lead came in most recently, which owner has the best qualification rate this quarter, or which accounts have open deals but no new leads. Things that used to need an export now take a few seconds. In practice this is the feature people mention first when they talk about the app. Want to see how the agent itself was built? We covered that in our earlier post on how we connected an Azure AI Foundry agent to Dynamics 365 for the same client. The AI agent answering a question about the most recent active lead. Shown with demo data. How It Works You do not need to be technical to follow this. There are really only four moving parts. Step oneSign in as usualSame Microsoft account, nothing new to remember Step twoPower Apps opens the appInside the platform you already use Step threeYour custom screensNumbers, charts and lists in your layout Step fourLive CRM dataAlways current, never copied How the pieces fit together, including the AI agent. A few things matter here for the business. People only see the records they were already allowed to see in Dynamics 365. There is no separate portal to pay for or look after. And because the app sits inside a normal Dynamics 365 solution, moving it from testing to live was as routine as any other release. Worth knowing before you start Users cannot save their own personal views in this kind of app, so the filters need to be planned with the team up front. Very heavy reporting may still be better in Power BI. And it is built by a developer rather than configured, so plan for someone to own small changes after go live. Impact One place for the whole story. Leads, pipeline, sales and delivery sit side by side instead of in four corners of the CRM. Questions get answered on the spot. The AI agent handles the ones nobody built a chart for. No new licences or logins. It runs on what the client already owned, under the security they already manage. Is This Right for You? Code Apps are not a replacement for everything in Dynamics 365. This is how we usually explain the choice to clients. This projectCode App Standard Dynamics 365 app Power Pages Who it is for Your own team, when they need a view built around their role Your own team, for everyday record work … Continue reading How a U.S. Industrial Cybersecurity Company Built a Custom Sales Portal with Power Apps Code Apps →

Please find this CloudFronts Product at – Integration Module between Dynamics 365 Project Operations and Finance & Operations | Microsoft Marketplace Summary Manually creating custom fields in Dynamics 365 Project Operations across multiple environments is time-consuming, error-prone, and blocks automation. This challenge can be addressed by using Dataverse Metadata OData APIs to programmatically create, update, and publish custom attributes during deployment. The process involves authenticating with Azure AD, calling Metadata API endpoints to create attributes, and publishing the changes with the PublishXml action, all through a fully automated approach. As a result, organizations achieve zero manual intervention, environment consistency, integrations, reduced human error, and a reusable framework that can be applied across all field types. Please find this CloudFronts Product at – CloudFronts – PO-FO Connector Table of Contents Introduction Business Challenge Why OData Metadata APIs? Implementation Procedure End-to-End Working Why This Approach Works Real-World Use Cases Conclusion Introduction When integrating external business applications with Microsoft Dynamics 365 Project Operations, it is common to discover that every customer requires additional fields to store information originating from ERP systems, manufacturing platforms, pricing engines, or product lifecycle management systems. For one of our internal projects & Prospect PoC implementing product-centric integrations, we needed a way to provision these custom fields automatically during deployment. Traditionally, creating new columns involves opening the Power Apps Maker Portal, adding fields manually, publishing the table, exporting a solution, and repeating the same process across multiple environments. While this approach works for occasional changes, it quickly becomes a bottleneck for automated deployments and CI/CD pipelines. The Solution: CloudFronts implemented a fully automated approach using the Dataverse Metadata OData APIs, enabling integration deployments to create and publish new Project Operations attributes programmatically. Business Challenge The customer’s integration platform exchanged large volumes of product and financial information with Dynamics 365 Project Operations. Each deployment required several custom attributes such as: Product identifiers ERP reference numbers Financial synchronization IDs External integration keys Processing status fields Creating these fields manually across Development, Test, UAT, and Production introduced several challenges: Manual configuration effort (time-intensive) Human errors (typos, misconfigurations) Environment inconsistencies (field variations across environments) Longer deployment windows Difficult CI/CD automation The Objective: Allow the deployment process itself to provision any missing attributes before importing data, eliminating manual touchpoints entirely. Why OData Metadata APIs? Most developers use the Dataverse Web API for CRUD operations on business records. However, Dataverse also exposes Metadata APIs, allowing developers to programmatically manage the schema itself—including tables, columns, relationships, and option sets. Microsoft documents creating attribute metadata by posting to the Attributes navigation property of an entity definition. This means integrations can: Create new columns dynamically Update existing metadata Publish customizations instantly Eliminate manual portal work Scale across multiple environments consistently Unlike traditional manual solutions, the Metadata API approach is fully programmable, auditable, and repeatable. Implementation Procedure Step 1 – Authenticate with Dataverse The integration first authenticates against Azure Active Directory using an application registration and retrieves an OAuth Bearer Token. That token is then supplied with every Metadata API request. Authentication Flow: Register application in Azure AD Configure permissions for Dataverse access Obtain OAuth 2.0 Bearer Token Include token in Authorization header for all API calls Step 2 – Creating a Custom Attribute The Dataverse Metadata API exposes the following endpoint for creating new attributes: POST /api/data/v9.2/EntityDefinitions(LogicalName=’msdyn_contractlineinvoiceschedule’)/Attributes Instead of creating business records, this endpoint creates metadata at the schema level. For this implementation, we created a new string attribute with the following properties: Schema Name: int_fnoid Display Name: FNO ID Data Type: String Maximum Length: 100 The request body uses the Microsoft.Dynamics.CRM.StringAttributeMetadata type together with standard metadata properties such as SchemaName, DisplayName, RequiredLevel, and MaxLength. Supported Metadata Types: Microsoft supports multiple metadata types through the same endpoint including String, Decimal, Boolean, Picklist, DateTime, Lookup, Currency, and more. Step 3 – Publishing the Metadata Creating an attribute does not immediately make it available. Like changes made through the Power Apps Maker Portal, metadata created through the Web API must also be published. This is accomplished using the PublishXml action. POST /api/data/v9.2/PublishXml The request specifies the entity to publish. After publishing completes successfully, the new attribute immediately becomes available throughout Dynamics 365. End-to-End Working The complete deployment process follows these steps: Integration authenticates with Azure AD. Dataverse access token is generated. Metadata API checks whether the required attribute exists. Missing attributes are created automatically. PublishXml is executed. New attributes become available. Product synchronization begins. External systems start populating the new fields immediately. Integration Points: This Attribute creation setup can be utilized across Logic Apps, Plugins, Azure Functions, and other Custom Workflows. Why This Approach Works ✓ Fully Automated Deployments No manual intervention is required when new integration fields are introduced. ✓ Environment Consistency Development, Test, UAT, and Production remain synchronized because every environment provisions the same metadata through code. ✓ CI/CD Friendly Metadata creation can be incorporated directly into Azure DevOps or GitHub deployment pipelines. ✓ Reusable Framework The same framework can create String, Decimal, Currency, Lookup, Date, Option Sets, and Boolean fields. ✓ Reduced Human Error Eliminates mistakes caused by manual customization and inconsistent naming conventions. ✓ Prevented Duplication Eliminates duplication of records, preventing system garbage in the database. Real-World Use Cases Use Case 1: PO-FO Integration (Project Operations to Finance Operations) For enterprises running integrated Project Operations and Finance Operations modules, this approach ensures that: ERP reference numbers sync automatically across all linked tables Financial synchronization IDs are created before data import External integration keys propagate consistently Processing status tracking fields exist in all dependent entities No manual re-entry of attribute definitions across environments Impact: Reduces deployment time from hours to minutes, eliminates sync mismatches between PO and FO modules, and enables real-time data reconciliation. Conclusion For an internal project and prospect PoC implementing product-centric integrations, automating metadata creation transforms what was previously a manual administrative task into a repeatable deployment process. Rather than relying on solution imports or manual customization through the Power Apps Maker Portal, integrations can now provision required Project Operations attributes on demand … Continue reading Automating Attribute creation in D365 Project Operations, Using Dataverse OData Metadata APIs for an Internal Project Operations–Finance & Operations Integration →

Summary SIP Industries is a Houston-based manufacturer of engineered components. Every new part it makes goes through a six-stage New Product Development (NPD) Business Process Flow in Dynamics 365. Most of the people who approve those stages never open the CRM. They include plant engineers and QA inspectors in India, the U.S. engineering team and customer reviewers. They replied by email, and the CRM team typed each reply into the NPD record and then clicked Next Stage by hand. We replaced that manual relay with three Power Automate flows, plus a small daily reminder flow. Each approver gets an email with one button, which opens a pre-filled HTML form that needs no login. The flows save the answers to Dataverse and move the stage forward once its conditions are met. Nobody keys in approvals or moves stages by hand any more. SI SIP IndustriesEngineered components manufacturer, Houston, Texas Industry Manufacturing Region United States StackDynamics 365 SalesPower AutomateMicrosoft DataverseSharePoint Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Business Impact→ Conclusion→ Connect With Us→ Business Challenges SIP already had a working NPD Business Process Flow on a custom New Product Development table. The stage design was sound. The time went into one recurring loop that the CRM team ran by hand for every stage of every part. New Product Development View A CRM user emailed the approver for that stage and attached or linked the latest drawing The approver replied in the thread, often with a one-line "go ahead" and an estimate buried in the text The CRM user read the reply and typed the decision, notes and dates into the NPD record The CRM user opened the Business Process Flow and clicked Next Stage The CRM user emailed the next team to tell them it was their turn That loop broke down in four specific places. Licensing the approvers was never realistic. A customer reviewer who signs off a sample twice a year does not need a Dynamics 365 seat, training and a password to remember Some stages close on more than one decision. Feasibility needs feasibility approval, engineering approval and a created engineering drawing. First Article Inspection needs both the India QA team and the U.S. engineering team. These approvals arrived in any order and someone had to keep track of which were still missing Drawing approvals stalled for weeks. Nothing reminded the reviewer, so follow-up depended on a CRM user remembering to chase The audit trail lived in personal mailboxes. Opening the NPD record told you the current stage, not who approved it or when Solution Overview We put an email-driven approval layer on top of the existing NPD process. When an NPD record reaches a stage, Dynamics 365 emails the approver for that stage. The email is written for that stage, so a Pattern request shows pattern details and an inspection request shows inspection details. It ends with one button. Engineering Approval Request Received in Outlook The button opens a web form in the approver’s browser, already filled in with whatever the NPD record holds. The form lists the product’s SharePoint documents and accepts new uploads. The approver picks a decision, adds notes and submits. Feasibility Approval Form Dynamics 365 then saves the answers into the right NPD fields. It moves the process to the next stage if that stage’s conditions are now complete, and the next approver gets their email. A rejection or a "Requires Changes" answer keeps the record in its current stage and notifies the NPD team instead. ⓘWho still uses the CRM The NPD team still works in Dynamics 365 and can set any field directly. The automation responds to changes made in the CRM in the same way as changes made through a form. Technical Approach Architecture at a Glance TriggerNPD record savedStatus or an approval field changes Flow 1Send Approval EmailTracked email with a stage-specific button Flow 2Show Approval FormReturns pre-filled HTML for the stage Flow 3Save Approval ResponseWrites answers and uploads to Dataverse and SharePoint DataverseBPF advancesNext stage starts and Flow 1 fires again These three flows run the entire approval loop, and the loop closes itself. When Flow 3 saves an answer, the NPD record changes, and that change triggers Flow 1 again. Flow 1 then either moves a stage whose conditions are now all met or sends the next approver their email. Alongside the loop, a separate reminder flow runs once a day and chases open drawing approvals. Six Stages, Eight Forms New Product Development Form Stage Approver Form Captures Stage Closes When Feasibility Feasibility team, Engineering team Feasibility approval, engineering approval, notes, estimated development timeline, estimated tooling cost Both approvals recorded and engineering drawing created Drawing Approval Drawing reviewer Drawing received, sample required, feedback, approval Reviewer approves on the form Pattern Plant and tooling team Pattern status, foundry, notes Pattern Status set to Ready For Inspection First Article Inspection India QA, U.S. engineering FAI approval and date, sample sent to U.S., shipment date, U.S. approval and comments Both India and U.S. approvals recorded Customer Approval Customer Yes, No or Requires Changes, with the approval date set automatically Customer answers Yes Production Production team Release notification Final stage NPD stages, approvers and the condition that closes each one Six stages produce eight forms because two stages have two separate approvers. Feasibility has one form for the feasibility team and one for engineering. First Article Inspection has one for India QA and one for U.S. engineering. Each form is identified by a stage key: feasibility, engineering, drawing, pattern, fai, fai_us, customer and production. Each form shows only the fields that apply to the record. The India FAI form asks whether a sample was sent to the U.S. only when the drawing reviewer marked a sample as required. It asks for the shipment date only after the sample has gone. Why the Form Lives Inside Power Automate Criteria Power Pages Canvas App Our choiceHTML form from Power Automate Approver opens it without signing in ✗ ✗ ✓ No … Continue reading How a U.S. Castings Manufacturer Saved Time by Updating Dynamics 365 Without Logging Into CRM →

At a Glance A client in Abu Dhabi discovered more than 400 posted G/L entries with incorrect dimension values. Using Dimension Correction in Microsoft Dynamics 365 Business Central, the finance team was able to correct the dimension values in bulk without creating reversal or adjustment entries. The corrections could be validated, audited, reviewed, and undone, providing a controlled approach to fixing posted transactions. However, it is important to note that Dimension Correction applies to G/L entries only; related sub-ledger entries retain their original dimensions. Table of Contents Introduction Why Dimension Errors Happen in the First Place What Dimension Correction Actually Does Setting Up Before the First Correction Step 1: Starting the Correction from the Ledger Step 2: Selecting Entries in Bulk Step 3: Defining the Dimension Changes Step 4: Validating Before You Run Step 5: Running the Correction Step 6: Reviewing, Undoing and Auditing A Note on Cost Accounting The Outcome Best Practices We Recommend Conclusion Frequently Asked Questions About the Author Introduction Dimensions are what turn a general ledger from a list of numbers into something management can actually use. A single expense posting tells you how much was spent; the dimensions on that posting tell you which department spent it, on which project, at which location. When dimensions are right, reports by cost centre, business unit or project take seconds to produce. When they are wrong, every one of those reports quietly becomes unreliable. That was the situation one of our clients in Abu Dhabi found themselves in. During routine month-end review, their finance team noticed that a large group of posted transactions carried the wrong dimension values. Some entries were tagged to the wrong department, others to the wrong project, and a few had no value at all where one was expected. By the time the pattern was traced, more than 400 general ledger entries were affected. Reversing and re-posting each transaction was not an option. It would have doubled the number of entries in the ledger, cluttered the audit trail and taken days of effort. Editing entries one at a time was equally impractical. Instead, we used the Dimension Correction feature in Microsoft Dynamics 365 Business Central to fix all of them in a controlled, bulk operation, without touching the amounts or the accounts. This blog walks through how the feature works, how we applied it for this client, and what to keep in mind before you run a correction in your own environment. Why Dimension Errors Happen in the First Place In our experience, incorrect dimensions rarely come from a single cause. For this client, the errors came from a mix of everyday situations that most finance teams will recognize: 1. Default dimensions not updated after an internal restructuring, so new transactions kept inheriting the old department code. 2. Manual journal entries where users picked a similar-looking value from the lookup list. 3. Recurring journals that were copied forward month after month with an outdated project code. 4. Imported data from a spreadsheet where the dimension column was shifted by one row. None of these errors affected the trial balance. The debits and credits were correct and the accounts were correct. What was wrong was the analytical layer on top, which meant that department-wise P&L and project cost reports no longer matched reality. What Dimension Correction Actually Does Dimension Correction lets an authorized user change the dimension values on general ledger entries that have already been posted. It does this without creating new journal lines, reversals or adjustment postings. The amounts, dates, document numbers and G/L accounts stay exactly as they were; only the dimension set linked to each entry is updated. Every correction is recorded as its own document with a description, a status and a list of the entries it touched. That means auditors and finance managers can always see what was changed, when, and why. Important limitation The correction applies to G/L entries only. Related sub-ledger entries, such as customer, vendor, item or fixed asset ledger entries, keep their original dimensions. Since the purpose of the feature is accurate financial reporting, this is by design, but it is worth communicating to anyone who reports from sub-ledgers. Setting Up Before the First Correction Before our client’s finance team ran anything, we put two controls in place. 1. Decide who can correct dimensions Access to the feature is governed by the D365 DIM CORRECTION permission set. We assigned it only to the finance controller and one senior accountant. Users with this permission can create, run and undo corrections, so it should not be handed out broadly. 2. Protect dimensions that should never change On the Dimension Correction Settings page, you can list dimensions that are blocked from correction. For this client, we blocked the dimension used for statutory entity reporting, since any change there needed a formal adjustment rather than a re-tag. Step 1: Starting the Correction from the Ledger A correction can be started from two places: 1. General Ledger Entries page, using the Correct Dimensions action. This is the most flexible starting point when the affected entries are spread across many postings. 2. G/L Registers page, by selecting a register and choosing Correct Dimensions. This pre-loads all entries from that register and is useful when a single batch posting went wrong. Because the client’s 400+ entries came from different journals and dates, we started from the General Ledger Entries page. The first thing we filled in was the Description field, with a note explaining the reason for the change and a reference to the internal approval. It takes ten seconds and saves a lot of questions six months later. General Ledger Entries page showing the Correct Dimensions action. Step 2: Selecting Entries in Bulk This is where the feature really earns its place. Instead of picking entries one by one, the Selected Ledger Entries FastTab offers several ways to build the list: Option How we used it Add by Filter Filtered on G/L account range and posting date range to pull … Continue reading How an Abu Dhabi-Based Diversified Holding Company Corrected Mis-Tagged Ledger Entries in Dynamics 365 Business Central →